
To: John Matthieson, Atari Corp		FAX: +1 408-745-8861
From: Michael Beaton			FAX: +44 482-573136


Dear John,


Here are some more reports on observed behaviour of the blitter, along
with some further ideas for minor(?) mods which might be useful in
a future chipset.

I hope this stuff is reasonably useful; do let me me know one way or
the other.


BLITTER
-------

When rotating from one 1 bit per pixel bitmap to another the image gets
corrupted, apparently because the choice of source pixel from within each
input byte is not correctly calculated on a pixel by pixel basis (the
image only looks correct when the scan is straight left to right).

The clipping mechanism generates write inhibits, but unlike the other
write inhibits on the blitter, these can't be overridden with BKGWREN
to cause the destination data to be written back instead of no write.
If the clip write inhibits could go through the same path, then, for
example, a small window which is filled with a blit from a larger
bitmap could have zeroes written outside the edges of the valid
data from the larger bitmap.

It would also be useful to have a PATDBKG bit, which causes the pattern
data to be used as the background colour rather than the destination
data when a write inhibit occurs. Then you could do the above 'window'
effect, even on blits of less than 8 bits per pixel for which the
destination data register is already in use.

Did you have any further thoughts about whether it would be possible
to initialise pixel mode bit-to-pixel expansion differently, so that
it will select the correct pixels whatever the size & shape of the
blit? (And, on a similar vein, although I've never needed it, is it
possible to remove the restriction on phrase mode bit to pixel
expansion that the source start must be on a phrase boundary?)

I hope you're still considering the idea of DDA's (& prefarably
clipping) on both address registers. That would give all the
texture mapping performance that most people need.


OBJECT PROCESSOR
----------------

I don't know whether the firstpix field is used much by anyone, but I
personally would find it very useful to have a bit which modifies
the effect of firstpix, so that the data at the right of the picture
gets filled out all the way to the end of the last image phrase (as
opposed to the current system, where zeroes get shifted in), this
would enable the effect of scanning a small view window over a larger
data area within the object processor.

It would be very useful to have a mechanism in the object processor
whereby an object whose top coordinate has gone off the top of the
screen gets fixed up automatically (i.e. the data start, height
and even scale info, if appropriate, all get stepped forwards by
the number of lines missed, the first time the object is
encountered). Any hope of that one?!

Here's one I mentined ages ago, which should be very easy: sign extend the
data width field, this would let you flip bitmaps vertically as well as
horizontally within the object processor. (I can't believe that anyone's
really got a data width which uses the top bit of this field; just how
compatible do you have to be, anyway!?).

I don't know if you know that you can make an RMW CRY object appear
transparent in its original colours, if you XOR each pixel of the image
with 0x8880 before setting the RMW flag; so a bit which modified RMW to
do this for you on the fly would come in handy.



O.K., that's it!


Yours sincerely,



Mike Beaton.
